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LOGISTICS SYSTEM FOR AUTOMATING 
TRANSPORXmON OF GOODS 

This is a division of U^. patent application Sec No. 
08/128358 entitled "Logistics System for Automating 
Transportation of Goods", filed Sep. 28, 1993, now US. Pat 
Na 5,485369. 

BACKGROUND OF THE INVENTION 

The present invention relates generally to computedzed 
systems for Gcpedidng tiie shq>ping of goods in commerce. 
More paiticularly, the invention relates to a compiiterized 
logistics system for managing and integrating various 
aspects of order processing, order fulfillment and goods 
transportation and tracking. 

In the past, con^uterized systems for expediting the 
shipping of goods have fallen into two rather diverse cat- 
egories. At the low cost end of the spectrum have been the 
standalone postage meters and mail manifest systems used 
by small businesses to automate the package weighing and 
carrier manifest printing functions. At the other end of the 
spectrum are the mainfirame conq>uter-based systems 
enq>loyed by large nationwide mail order merchandisers. At 
both ends of the spectrum the systems have had a number of 
limitations. 

The standalone mail manifesting systems are limited in 
that they are designed to automate only the sh^>ping func- 
tions such as printing mailing label and mailing manifest by 
the sh^jping derk or shipping department. As such, the 
conventional standalone system was not integrated with the 
customer order department or with the order fulfillment and 
order packaging departments. Hence, conventional standa- 
lone systems have lacked the ability to take order size, 
package size or time in transit into account when selecting 
the least cost carrier 

Large mainframe order processing systems are also lim- 
ited. Due to the complexity of mainfirame computer archi- 
tecture and associated software systems, it is not practical to 
use these solutions in the small or moderate sized business 
environment Mainficame-based systems often require years 
to develop and to customize for a particular organization*s 
needs. Thereafter, large data processing departments are 
needed to maintain the system and keep it operationaL 

The present invention provides a high-performance, cost- 
effective logistics system which is readily adaptable to a 
wide variety of different organizations. Tlie system is suit- 
able for deployment on a single, standalone con^niter or on 
a conq>uterized network coII^)r^sing many con^utcrs. 
Among the advantages of the present system are (1) sub- 
stantial reduction in freight costs; (2) a major increase in 
fulfillment accuracy; (3) convenient order tracking to £adli- 
tate warranty, lot and serial number tracking; (4) in^sroved 
customer service; (5) a readily customizable system which 
can be adapted to virtually any shipping opoation; (6) a 
robust system having a long useful life; (7) graphical user 
interface screens for easy training and use; and (8) greatly 
reduced inqiiementadon costs in a system with increased 
effectiveness. 

As mare fully described herein, the logistics management 
system of the invention fiadliCates iho process of shipping 
goods by a sh%>per having a predefined set of shqyping 
requirements via a carrier having a predefined rate structure. 
The system enq>loys a multitasking operating system envi- 
ronment for running a plurali^ of conq)uter processes 
substantial^ simnltaneously. Tlie environment has a means 
for interprocess communication v^ereby messages may be 
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passed between tbe con^uter processes. A supervisoiy 
server, running in the operating system environment, pro- 
vides registration services to connect one or more conq>iiter 
processes to &e inteiprocess commanication mechanism. 
The system furtfier cnsplcfys at least one rate server, also 
nimiing in &e cperadng system environment, substantially 
simultaneously with the siq>ervisary server: llxe rate server 
or servers provide access to carder rale structure data and 
also provide predefined data processing services using the 
carri^ rate structure data in response to a predefined set of 
request messages. The predefined data processing services 
indude the providing of response messages based at least in 
part on the cacda rate structure data. More specifically, the 
rate server or servers have registration means for commu- 
nicating with the supervisory saver to invoike the registra- 
tion services of the supervisory server and diereby es^Iish 
a connection to the interprocess conununication means. In 
the presently preferred embodiment tiiere is one rate server 
for each carder (e.g., U.S. Postal Service, Federal BiqiTess, 
United Parcel Service, etc.) and these servers are provided 
with a conq)lete knowledge base of all rate structure data and 
shipping rules and regulations pertaining to that carrier. 

In addition to fiie supervisory server and one or more rate 
servers, die logistics managements system also includes at 
least one client process running in the operating system 
environment substantially simultaneously widi the supervi- 
sory server and also with the rate server or servers. The 
client process has a user interface for coUecting input 
information from a user about a desired operation and for 
providing output information. More specifically, the client 
process also has registration means for communicating with 
the supervisory server, to invoke the registration services of 
the supervisory server, and thereby establish a connecdon to 
the inteiprocess communication means. The client process 
has a preprogrammed set of rules which are reflective of a 
given shipper's predefined set of shipping requirements. The 
client process also has a processing means for using the 
preprogrammed set of rules and using at least a portion of 
the input information to issue request messages to one or 
more rate servers and to interpret response messages 
received from fiie rate servers in order to provide the output 
information. In the presently preferred embodiment the 
client process is preprogrammed with a knowledge base to 
reflect the shying organization's rules, regulations and 
practices. In this way, the client process presents a familiar 
view of day-to-day operations, as seen by the organization's 
personnel who are responsible for taking orders, pabkaging 
goods and shipping goods to customers. Because the some- 
times complex rules and regulations of the carders are fulty 
handled by the rate servers, users interacting with the client 
process do not need to have a full and con^>lete understand- 
ing of the carrier's rules and regulations in order to propedy 
sh^ goods in a cost-effective and timely manner: 

• As marc foBy set forth herein, the siq>ervisory server, tkic 
rate server or servers and the client process or processes are 
interoperable througji the interprocess communication 
means (a) to receive input information from a user via the 
user interface of the dient process, (b) to use tb& iitput 
information to issue a request message to the rate server via 
the interprocess communication means, (c) to process the 
issued request message and thereby cause a response mes- 
sage to be generated by the rate server, (d) to send the 
response message to the client process via the interprocess 
communication means, and (e) to provide output informa- 
tion based on the response message. The output information 
can range firom siII^)ly displaying information on a screen to 
the user, to printing a niafling label or manifest or to 
updating records in a conopany database. 
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For a more complete understanding of the invention, its 
objects and advantages, reference may be had to the follow- 
ing specification and to the accompanying drawings. 

BRIEF DESC3UFTrON OF THE DRAWINGS 

FKj. 1 illustrates an example plication in which the 
logistics management system of the invention may be imple- 
mented; 

FIG. 2 is an icon view of die plurality of program objects 
which compose a presently preferred embodiment of the 
logistics management system; 

FKx. 3A is a block diagram depicting a distributed archi- 
tecture embodiment of the invention; 

FIG. 3B is a block diagram illustrating a single, standa- 
lone CPU embodiment of ttic invention; 

FIGS- 4A-^L, inclusive, represent exen^lary user inter- 
face screens of the presently preferred embodiment; 

HG. 5 is a block diagram illustrating the presently pre- 
ferred mechanism for implementing the client/server 
architecture, illustrating how multQ)le threads operate in the 
presently preferred embodiment; 

FIG. 6 is a block diagram illustrating the presently pre- 
ferred tree-structured client/server communications mecha- 
nism 

DESCRIFnON OF THE PREFERRED 
ENfBODIMENT 

The logistics system of the invention serves as a man- 
agement tool for the automated order processing, packaging, 
sh^yping and transportation of goods. The system is highly 
flexible and adaptable and tiius the invention can be imple- 
mented in many forms. Therefore, in crder 'to illustrate the 
principles of the invention an exemplary order processing, 
packaging and shipping operation wiU be illustrated and 
described. It will be understood that the invention provides 
a collection of building blocks or program objects which can 
be assembled in a van^ of different ways to easily con- 
struct a logistics management system for practically any 
^>plication. 

Refening to FIG. 1, an exexiq>lary application is illus- 
trated. In FIG. 1, a networked architecture is illustrated in 
which a plurality of con^>uters are interconnected by a local 
area network bus 20. Of course, the number of computers 
and the network architecture utilized are matters of design 
choice. The invention is not restricted in this regard and will 
operate on systems as small as a single standalone con^uter 
and as large as a global-wide area network. 

FIG. 1 illustrates a sinq>le system which includes an order 
processing station 22, a packaging station 24 and a shying 
station 26. Hie order i^ocessing station might ordinarily 
include one or more conqjuter terminals through );^ch 
order entry personnel input a oistomer's order. The order 
entry terminal may be integrated with a point-of-sale termi- 
nal cash register or it may be associated with or connected 
with a telephone system through widch customer orders are 
p l ac ed. In this regard, while most order entry tenmnals are 
designed to be operated by an order processing derk, direct 
order entry by tfie customer via computerized telecommu- 
nicatiotts equipment is also envisioned. 

The order packaging station may also compd&c one or 
more computer terminals to which a bar code scanning 
device 28 may be optionally attached. Ihe scanning device 
would be used, for exanq)le, to scan the universal product 
code (UPC) of each item as it is picked from the warehouse 
didves and placed into the sfa^iag container 30. 
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The shipping station 26 sinulady may indnde one or 
more computer terminals to which a scanning device 32, 
electronic scale 34 and mailing label printers 36 may be 
attadied. Preferably, the printers axe capable of iffinting Ihe 
accessary shipping documents, bills of lading, manifests and 
so forth, as well as the a pprop riate package labeling. IS 
desired in the alternative, the package labd may be pre- 
printed (e.g. at the packing station) and the scanning device 
32 may be used to read the labd and thereby automatically 
enter the package identifying number into the system. 

The logistics management system of &e invention may be 
implemfntf^y in software and run from a variety of different 
conq>uter platfonns. Preferably, at least portions of the 
logistics management software are installed and run on each 
of the conputer terminals illustrated in FIG. 1. In addition, 
the logistics management system software may also be 
installed and run on other computers attadied to tiie 
network, sudi as conq>utcr 3S. As will be more fully 
described bdow, the logistics management system is also 
capable of interfacing with non-native con:q)uter systems, 
e.g., previously existing conq)any database systems, via an 
external processing management system. To illustrate this, 
an external database 40 is depicted in FIG. 1. The database 
may be resident, for example, on a mini-con^uter or main- 
frame con^uter used to store con^any finandal records. If 
necessary, the external database system may be connected 
via a gateway 42 to the local area network bus 20. 

Client/Server Ardiitecture 

The presently preferred logistics management system is 
implemented using a dient/server architecture and a multi- 
tasking operating system. Although the present^ preferred 
system runs under the OS/2 operating system, use of OS/2 
is not a requirement Any multitasking operating system can 
be used. A mnltitasklng operating system was sdected for 
the preferred embodiment because it permits multiple pro- 
cesses (and multiple threads) to run effectivdy simulta- 
neously. The mnltitaskiug operating system thus allows 
multq)le programs to run effectivdy simultaneously and to 
communicate with eadi other through an inteipcocess com- 
munications (EPQ mechanism. 

One benefit of the multitasking operating system is that 
the present invention allows the logistics management task 
to be split into multiple pieces. This ardiitBCture is quite 
advantageous since it allows updates or dianges to be 
effected with respect to part of the system without affecting 
the rest of die system. The diem/server ardiitecture derives 
benefit from the multitasking operating system by allowing 
the overall logistics management task to be subdivided along 
functional lines. As will be more fully explained bdow, the 
presently preferred embodiment places carrier-related 
information, sudi as sh^>ping rates, sh^iping rules, time in 
transit information and tiie like in one or more rate servers. 
These servers are responsible for making all determinations 
regarding how a given caxrier*s rules and rate structures are 
to be interpreted. The presently preferred embodiment facili- 
tates the particular shqyper*s requirements, such as crder 
, taking, order fulfillment, invented control and the like, in 
one or more dient i^Hcations. These client {plications 
may be customized to conform quite dosdy to a given 
shipper*s operation. These dient splications call upon the 
necessary rate servers, as needed, for the appropriate shi|>- 
ping rates and shipping requirements of ttit sdected carrier: 

The multitasking operating system and the dient/server 
ardiitecture of the preferred embodiment oonqsiises &e 
logical structure of the logistics management system. The 
physical structure, Le., how many computers are used and 
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how &OSC computers are interconnected, can vary widely 
and stUi inclement fbc above-described logical dient/servcr 
ardiitectiire. More specifically, the preferred embodiment is 
constructed to siq>poit distributed applications in which 
different pieces of the total dient^server structure are run on 
multiple machines interconnected together via a network. In 
general, tiiere is no limitation on how the respective client/ 
server conqionents are to be distributed across the network. 
Thus, for CKsanpltf in tiie system illustrated in FIG. 1, any of 
the computa terminals associated with stations 22, 24 and 
26, as weU as computer 38, may host one or more dient 
^yplications and one or more server qiplicadons. 

Hie present invention uses a plurality of program building 
blocks or program objects, each having a specific function 
within &e overall client/server architecture. The building 
blocks or program objects which make up the presently 
preferred embodiment are illustrated collectively in FIG. 2. 
HG. 2 is illustrated in die farm of a window or folder 50 
containing a plurality of icons, each representing one of the 
program objects which make up the preferred embodiment 
A bnef description of each of these objects is presented 
below. Further details of die manner in which these objects 
communicate with one anotiier and further details of the 
objects construction will be presented thereafter: 

The R^ently F!ref erred Program Objects 

The presently preferred program objects are described in 
Table I below. Broadly speaking, these object can be 
classified as beiag client objects or server objects. For 
exanqde, the objects bearing the designation "server" oi 
**manager^ function as server objects. The objects desig- 
nated as ^'dienf* or "administration" (admin) function as 
client objects. 

More specifically, servers such as rate servers encode die 
knowledge required to answer questions such as how to 
calculate shipment rates or how to band shipments. Thus, 
rate servers provide the knowledge regarding a specific 
carrier's requirements, lypically, rate servers are provided 
with specific details regarding a given sh^>ment*s weight or 
die required delivery date fay a client application. Also 
typically, rate servers do not have user interface screens. 
Servers sSmply appear as icons on the user's desktop and 
wait to be asked a question by a client Provided the question 
includes the right details, the server will then retum the 
correct answer to die client Servers can reside anywhere on 
a network, so tiiey may not necessarily be visible as icons on 
a particular user's conqniter soeen. 

Clients are principally responsible for asking specific 
questions of the servers. Clients have responsibility for 
gadiering and displaying information. As sudi, clients usur 
ally have user interface screens through which a user can 
enter data or input data through an attached scanning device* 

Manager objects are piincq)ally responsible for managing 
aspects of the logistics management system, such as the 
communication b^ween clients and servers, or communi- 
cation widi printers, scanners and die like. Administration 
objects are princqially responsible for providing a user 
interface mechanism ^^lereby die user may edit system 
settings and scr^ts. 

TABLEI 

Psogtsni Object FuQction 



Supetviscny Serven Acts as a nqxidtcay for system wide 

inronnatkaL 

Document Serven Manage die cEeat zeqoests fbr 



TABLE I-contiaued 



Program Object 



FbdEz Rate Server 

rPS Rater Servcn 
R^ Rate Server 
LIL Rate Server 

£xt foocess Maoa^ger 

Device Manager: 
Reset Database: 



Kotroducttoii to £be 

system: 

Reports; 

. Supervisory 



Sciq)t AdmimstratioQ: 

FedEx A A niTMj y ^ y m ion; 



UPS Rate 



RPS 

Search andlbice: 
Sbipmeots: 
Padcages: 
Bills of Ladii^g; 

i 

T^T^ Shipments* 



; Document 
Administiatiaa: 



pimtiqg of tiiose documents. 
Mana g rs the Federal Express ratea> 
caster rules and *^n ditT^ii^utirti | 



Manages the UPS rates, carrier rules 
and ^^'^•""r^iiiHtion tequircKQents. 
Managm Ac RPS rat^ carrier rules 
and documentatioii reqoirenients. 
M ant^ges fee UL rates, carrier roles 
and ^'[WMii^'^'^^^^^^Ti rfmiip^Tn^iifs. 
Acts as a repository for 

^^^^fw^^^^^^fflff iilffiwiia>^i || 

Ma nagrs (he client requests tar 
access to outside services such as 
remote databases and remote 



Manages the client requests for 
access to outside devices such as 
printers, gfann^^ aoij scale& 
Resets the sanq^le database to its 
default values to fe**^^*^^^ trainxqg 



A tutorial for the new user. 

Double-clicking this icon will run a 
third party report generator prpgram. 
Allows the user to edit system 
settings, manage shipper infarmation 
and allows users to scud messages to 



Allows the user to create and etfit 
scr^rts used by die 'P.^ti>mi»\ 
Processing Man^gn^ 
Allows tiie user to conQgure fl» 
Federal Express Server settixigs such 
as account cumbers, EDI settix^ azxl 
to close out the manifiKts. 
Allows the user to configure ^ UPS 
Server g*^^***ngff such as aoccvnt 
numbers, rates, cfiscounts and to close 
out die manifosts. 

Allows the user to configure the RPS 
Server such as account 

numbers, rates, Hiwninfy gnj to close 
out the manifests. 

Allows the user to configure the UTL 
Server settii^ such as account 
numbers, and rates, discounts and to 
close ouL 

A client predication which allows lie 
user to search and trace ^edfic 
packages, shipmrnts and prders. 
A client application which aBows Ibe 
user to process shqtments conqpErised 
of multqple packages per ordei: 
A client qiptlication which allows ibc 
user to process shqpments comprised 
typically of one package per ordec 
Allows the user to create bills of 

fyf TSTLr Motor Freight 
Shqnnents. 

Allows the user to create and rate bills 
of lading £or LIL Motor Freigfat 
Shipments. 

Allows the user to configure Ae 
Document Server with UCC-128 
Gcnal suQibcr '*i aTiit?n 

w-iinr^Ttt otttibutBSh 



Li an actual implemeiitation of the system, one supervi- 
SQiy server and at least one supervisory manager wo^d be 
. provided. Specifically, one (and only one) siq>eivisQry server 
is provided for the entire network In addition, one super- 
visory manager is provided for eadi CPU that will be 
running client or server applications on the n^orlLThis is 
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illustrated in FIG. 3A, which d^ucts a distributed aidiiteo- 
tuze eiiq>loying three networked CPUs l<k2, 104 and 106. As 
illustrated, the supervisory server and one snpervisoiy man- 
ager are running on CPU 104. Supervisory managers are 
also running on CPUs 102 and 106. For illustration purposes 
a UPS rate server object and a UPS rate administration 
object arc also running on CPU 102; whereas a shipments 
client and a device manager are running on CPU 106. Thus, 
FIG. 3A represents one possible configuration assembled 
from the collection of presently preferred program objects. 

Although mult^le CPU, distributed architecture installa- 
tions represent a powerful configuration, it is possible to 
implement tkic invention on a single, standalone, CPU. This 
is illustrated in FIG. 3B, in which a standalone CPU is 
indicated at 108. As illustrated, this simple configuration 
includes a supervisory server and supervisory manager, 
along with any other program objects which may be required 
for the task being performed. Thus, in die exan^de illus- 
trated in FIG. 3B several rate servers and a packages client 
have been illustrated. 

Application User Interface 

Referring to FIGS. 4A-4L, the presently preferred user 
interface will now be described. In general, the client/server 
program objects, illustrated as icons in FIG. 2, may each 
have a user interface in the form of a screen or window 
teoug^ which the user can enter information, make com- 
mand selections, and look up information. In practice, the 
user interface may vary in appearance and function, as 
dictated by the particular task to be performed. Thus the user 
interface screens illustrated in FIGS. 4A-4L are intended 
merely as examples in accordance with the presently ja-e- 
f erred embodimenL 

Overall Icon View — System Folder 

The presently prefenred embodiment places icons for all 
user-selectable program objects in the Logistics Manage- 
ment System folder or window, shown in FIG. 2. In this 
regard, the window shows a sample set of icons for the 
presently preferred systeuL Each icon is a pointer to a 
seperate dient, manager or server object By double-clickusg 
on tiie ap pro pri ate icon, its object is started. For example, 
douUe-dicking on the Shipments Client starts that program 
object running. Typically, once an object is started, it con- 
tinues to run and is able to communicate with otber program 
objects via the interprocess communications (JPC) mecha- 
nism. 

Shipments Client 

Shown in FIG. 4A, the Shq)ments client accepts user 
input for the routing, rating and documentation of a groi^ of 
packages comprising a shipmenL Multq)le shipper accounts 
are allowed and the desired account may by selected from 
the Sh^jpcr *'drop-box." Similarly, the service is selected 
from the Service box. Alternatively, the service msy be set 
to Best Way and the system will choose the least cost carrier 
which meets die transit time requirements indicated in tiie 
commitment field. 

Hie operator types or scans the Reference # (such as order 
#, pick ticket #,...) and die system may be set to look up 
the associated information firom one or more local and 
remote sources such as databases and mainframe or mini- 
con^uter terminal sessions. The upper left quadrant of the 
screen is to record information for the sh^)ment as a whole. 

The lower left quadrant is used to record specific infor- 
mation for each package in the sh^)ment In all client data 
entry screens diere are several special data entry provisions. 
Any field which has an ellq>sis (...) at its n0it edge has 
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additional related fields of data availahle to be **exanuaed** 
or edited by toucbing die FIO key or rfiglrfng the Ebcamine 
icon. Apopup window wi& the associated fields is displayed 
for the user. In addition, most fields may be set iip to 
"browse" availahle valid entries. They may browse fix>m 
database records or fi-om "hard-coded" values in scripts. 

The Shipments client and most other clients are capable of 
processing shipments of mixed modes; eg. small parcel 
ground, small parcel air, LTL motor freight, air frei^t, and 
TL motor freight. 

Packages Qient 

Shown in FIG. 4B, the Packages client is designed to 
facilitate the entry and processing of shipments which 
typically consist of single small packages. Although, like 
most other clients, it will handle mult^le modes of 
shipment, it is best suited for single piece shq>ments. If a 
mult i-piece sh^ment is encountered, the user may touch 
CTRL-M or click the Multi button and the shipment is 
accomodated. 

Script Administration 

The Script Administration object, shown in FIG. 4C, 
allows the creation and editing of scripts for the modification 
of default t>ehavior of ihc clients. A sc2q)t may be triggered 
in various ways, such as upon the changing of the contents 
of virtually any field, upon the pressing or clicking of the 
function buttons on &e client screen, upon the opening or 
closing of the dient, and so on. In the illustration of FIG. 40, 
the Sh^>ments client is being operated upon to modify the 
Commitment terms based on the type of Service being used 
by the shq>per. 

UPS Rate Adjustments 

Rcf cning to FIG. 4D, the UPS Rate Adjustments program 
objea and substantially similar objects for each of the 
carrier rate servers installed on the system, allow the user to 
adjust the discounts and incentive programs extended to the 
shipper by the carrier. Existing discounts may be edited, or 
new incentive programs not yet envisioned by the carrier 
may typically be created by tiie user within the flexible 
structure of this client type. Adjustments may be qualified by 
destination (either zone, postal code or destination country) 
and by weight range. Adjustments may be calculated as 
percentages or fixed amounts and include or exclude special 
service fees. If desired multQ)le adjustments may be created 
and put into effect 

Serial Port 2 Configuration 

The Serial Port 2 Configuaration screen, shown in FIG. 
4E, is a part of the Device Manager object It allows tiie 
adjustment of basic serial port setup values. By giicHng on 
the 'Defaults** button, the default settings 2^>propriate to the 
specific attached device are automatically entered. The 
j **Ibsr button provides a facility for sending data to and 
. receiving data from the attached device. Additional aspects 
. of the Device Manager object are discussed in connection 
j with FIGS. 4G-4L, bdow. 
i Document Administration 

' The Document Administration object, shown in FIG. 4F, 
allows the user to adjust settings for the UCC-128 standards 
of serialized container marking and Electronic Data Inter- 
change. It allows the user to load and store consignee names 
and addresses and UCC-128 specific values. It also allows 
the user to edit the database and settings as changes may 
occui; 
Document Server 

The document server, illustrated as one of the icons in 
FIG. 2, allows any client to print almost any type of 
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docoxnent, including sh^iping kbds, waybills and manw 
fests. The infoxmadon needed to print a document is pro- 
cessed through a sanpL This aUows the data to be farou^ 
in from any number of sources such as databases^ 
Tnainfiranie s, files ox user-entered information from a client 
i^Tplication. Also, one document format can serve several 
client ^jplications and any particular processing needs a 
user mig^t have. This is quite readily accon:q>lished due to 
die £ict that all data is passed tfarougji scripts. Thus, for 
cxanqde^ one user mig^ look up the export information for 
a FedEx international document from a database, while 
another user mig^ wish to hand enter this data. Both of these 
tasks can be accomplished by a single document format and 
without the need for custom programming. 
Device Manager Object 

The Device Manager provides a device-independent 
means of interfacing with peripheral devices. Device drivers 
can be added or removed without modifying the software. 
The Device Manager also provides integrated testing tools. 

Hie Device Manager of the presently prcfcnred embodi- 
ment has &e ability to monitor power, through an uninter- 
ruptible power supply coimected to the system, ff power 
fails, tiie other plications are notified, and an orderly 
shutdown of the system will take place. This prevents loss or 
corruption of data by sudden power outage or by subsequent 
failure of battery power, once the reserves of the unintex- 
iiiptfl>le power supply have been depleted. The monitoring 
service provided by the Device Manager can shut down 
multiple machines on a network connected through one 
uninterruptible power supply. 

Referring to FIGS. additional capabilities of the 

Device Manager object are illustcated. In FIG. 4G the 
communications port COM2 is shown as assigned or con- 
nected to an electronic scale, in this case a scale designated 
Toledo 82 13 Scale. The parallel port LFTl is shown as being 
assigned or connected to a printer, in this case a printer 
designated IBM 2380 Rinter. Beneath the printer designa- 
tion diere pears a notation *^o stockf* which indi cates that 
nopaiticularp:^ stock has yet been designated. 

Double-clicking on the COl^ icon brings up the con- 
figuration screen shown in FIG. 4E. Selecting die purl-down 
menu designated ^Device" brings up the device selection 
menu shown in HG. 4H. Using the device selection menu 
the Toledo 8213 Scale may be selected, as illustzated. 
Thereafter; by returning to the device manager menu of FIG. 
4G, file Toledo 8213 Scale icon may be double-dicked to 
bring up fixe device settings menu illustrated in FIG. 4L 

Alternately, from the device manager menu of FIG. 4G, 
the parallel port LFTl may be selected (by single-clicking) 
and configined fay again accessing the ^'Device'* menu 
option. In fius case, referring to HG. 41, the IBM 2380 
printer may be selected, as illustrated. Thereafter; the user 
may dick **GKr to return to the device manager saeen , FIG. 
4G. Fh>m the device manager screen the user can double- 
click on die printer icon to faring up the a ppr o pri ate device 
settings menu (FIG. 4K) for that device. Referring to FIG. 
4K, note tiie Current Stock states "No stock loaded." If 
desired, file us er can change the cunent stock by clicking on 
file diangc button. This action brings up the stock selection 
menu of FEG. 4L. 

DETAILED DESCRIPnON OF CLIENT/SERVER 
OBJECTS 

The dient/server architecture utilized by fiie logisdcs 
management ^stem affords a great deal of flexibility. Hie 
client and server program obje^ are designed to work 
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independently of one another, communicating with one 
anodier thxougfa a tokenized message hanffiing mftrhflniCTn 
discussed below. In this w^, rate server data and user data 
are separated £rom one another The advantage of Hds is that 
when a given canier changes the way rates are handled, the 
affected rate server can be modified (to diange the ^pe or 
amount of data stored in that rate server, for cxaanple) 
without affecting the user's data in any way. This separation 
is important since carrier requirements and earner service 
options may change at any time. 

The presently preferred embodiment Im plemen t an inter- 
nal version nuznbeiing sdieme which proWdes a mprftftni gni 
to allow client a^lications to determine what version of a 
server diey are communicating with. In so dodng, tiie dient 
applications are able to make any necessary adjustments or 
to disconnect from that server if inoon^atibilities are found. 
This provides greater reliability, since server plications 
are given the ability to handle communications with servers 
intelligently. 

Separation between dient and server objects also makes 
possible an automatic updating capability whereby a user's 
existing setup information is automatically merged into a 
new installation when an application is updated or rein- 
stalled. This reduces the amount of setup time due to 
reinstallation. 

Each server of the presently {xrefecred embodiment has 
built-in debugging capabilities whidi allow server transac- 
tions to be displayed on the screen or logged to a file for later 
analysis. The presently preferred rate servers optimize ship- 
ments to minimize cost through the use of shipment pricing 
rules supplied by the carriec Optimization occurs ''live*' as 
a shipment is being processed, or, alternatively, at tiie end of 
the day when all packages shipped are then optimized. The 
rate servers can directly access carrier-supplied data, sudi as 
Federal Express routing and rate file data. This allows the 
user to load in new rate information as soon as such 
information is provided by the cani^. In addition, the rate 
servers of the presently preferred embodiment have tiie 
ability to rate and process a package, but to withhold it from 
the manifest until notified to do so. This allows *^adc and 
hold" or fixture sh^>p^ng. This is in^Kxrtant in an automated 
system where a package may be processed upstream, tait not 
placed on the manifest until it readies die shilling dock. 

In the presently preferred embodiment dient plications 
have editable bar code templates, to allow data to be entered 
via a barcode scanner. Because the templates are editable, 
they can be added to, ddeted tcom or modified by the user 
widiout the need for additional psogcamming. Clients can 
also process in **batch'' mode, reading data from a source 
and sending that data to the propriate rate servers for 
processing. The sources for data can indude databases, files 
or direct connection to a host computer via serial or netwodc 
connection. 

As stated above, the presently pref ened embodiment uses 
a multitasking cyperating system which si^yports the process- 
ing of multq)le processes or multiple threads effectivdy 
simultaneously. This allows dient qtplications and server 
' applications to cperate effectivdy concurrently. To illustiate 
how multq>le tiireads operate in the presently preferred 
embodiment refer to FIG. 5. In FIG. 5, tiie left-most box 
designated main thread 120 repres^ts fiie starting point 
Main thread 120 is lanndied by the operating system. One 
of the functions of main thread 120 is to perform or control 
the performance of the operating system routines iUustrated 
in FIG. 5 by loop 122. When a server is started under the 
cperating system tilie main tiircad lanndies a server thread. 
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as rqxrese&ted by launch thread axrow 124. The server thread 
is rqxrescnted by box 126. In the prefcned embodiment the 
saver tiiread petfarms the necessary initialization routines 
128 and then enters a loop or state 130 where it waits for a 
client to initiate a connection request When such a request 
is received the server thread launches a client thread, 
depicted in FIG. 5 by launch thread arrow 132. The client 
thread is depicted by block 134 in FIG. 5. It is responsible 
for handling tlxc client's request Once the client thread is 
launched by the server thread, the server thread returns to its 
wait for dient loop or state 130, whereby Hit server thread 
is then able to launch additional dient threads upon demand. 
Thus in the preferred embodiment, each server ttiat is 
running will indude a main thread and a server toead. 
Client threads are generated on an as needed basis. There is 
one client thread for each currently connected dient 

Communication between client and server, whereby 
requests are passed to the server and responses passed back 
to the clients, may be acconq)lished in a variety of different 
ways. In general, the methods of conmiunicating between 
imiltiple processes running on the same CPU include shared 
memory, semaphores, pipes, queues and signals. The meth- 
ods of communicating between multiple processes miming 
on different CPUs (distributed ardiitecture) indude mecha- 
nisms such as NETBIOS, named pq>es, sockets and mail 
slots. Collectively all of these methods of comnmnicating 
between multiple processes form part of ttie interprocess 
oonmiunication (fPC) medianism. Not all multitasking 
operating systems provide eadi of these IPC mechanisms. 
The presently preferred embodiment runs under the OS/2 
operating system and uses LAN Server to provide operating 
system suppcft for a distributed aj^lication architecture over 
a network. The presendy preferred embodiment uses named 
pipes as the IPC mechanism. 

Named p^s allow one process to communicate with 
another process as follows. The client process first requests 
a named pipe connection to a server process. Once this 
connection is made, tiiere is Uttle distinction between the 
dient process and the server process, since dther can 
communicate with the other. One advantage of using the 
named pipe IPC mechanism is that the dient process 
machine does not have to be nmning under the same 
operating system as the server process. All that is required 
is that the operating system platform on which the dient 
process is running wUl support named pipes. Thus, a dient 
process running under MS-DOS, or under MS-DOS with 
windows, for exan^le, could establish communication with 
a server process running under the presently preferred OS/2 
system, provided named pipe communication is supported. 
Essentially, under a named pipe communications scheme, 
ttie server process is known by a pipe name. I^rograms 
wishing to connect to that server will use the pipe name, in 
a fashion similar to using a file name. For example, p^>e 
names may take the f oon: 



VFIFE^^ename; or 
\\seTvez\FIFESp^eiianie. 



Although the named p^ IPC mechanism permits oomr- 
nmnication between any server and any dient, the presently 
preferred configuration constrains communication to a tree- 
structured communications sdieme illustrated in FIG. 6i. 
Refening to HG. 6, the single supervisory server commu- 
nicates directly with only supervisory managers. In FIG. 6 
the lines of communication are designated by the letter *X7* 
at one end and the l^ter **S** at the o&er end. These indicate, 
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for a given line of comnmnication, which object is Ihe dient 
and which object is the scrvcn Thus each of the supervisory 
jnajiagers coxnixuinicates as the client with the supervisory 
server. In a similar fashion, the rate server, label server, 
external processing manager and device manager all com- 
municate as clients with the supervisory managers, as serv- 
ers. Likewise, the rate server administration object, the 
shipping client and the device manager administration object 
all communicate as clients with one or more of the objects 
appearing above them in HG. 6 (namely rate server, label 
server, external processing manager and device manager). 
Thus it will be seen that certain objects function in a dual 
capacity, serving as dient objects in some instances and 
serving as server objects in other instances. 

The presently prefen'ed communications scheme permits 
objects to comnmnicate with devices, external databases and 
other compute systems which are not part of &e client^ 
server logistics management system. To accommodate this 
certain objects are given the ability to conummicate with the 
outside world. These objects indude the device manager, 
which communicates with hardware devices, such as 
printers, bar code scanners, modems, postal scales and the 
like. Communication with external databases and other 
programs which do not form a part of tiie dient/servcr 
logistics management system (e.g., accounting software 
packages, spreadsheet programs, operating system utilities 
and the like) are communicated with through the external 
processing manager. 

Because the presently preferred embodiment can be 
implemented in multiple CPU environments (distributed 
ardiitectute), an announcement mechanism is provided in 
order to extend the communications scheme to multiple 
CPUs across a network. Hie supervisory managers are 
preprogrammed with the ability to send ^^announcements" 
across the network operating system according to the named 
pipe protocol which has been iii^lemented. Thus, as illus- 
tiated in FIG. 6, each of the supervisory managers indudcs 
a communications pathway designated "announcements" 
throu^ which communications with parts of the system 
operated by different CPUs are sent and received. The 
supervisory managers are not, themselves, responsible for 
coordinating this message passing between objects con- 
trolled by different CPUs. That function is reserved for the 
supervisory server, since the supervisory server occupies tiie 
unique position of controlling the re^stration process 
whereby client and server ^yplications are made aware of 
each other in order to conmumicate. However, in order to 
distribute die announcement function, the supervisory man- 
agers are responsible for providing the actual announcement 
communications. In this regard, the supervisory managers 
act as servers, with die supervisory server in this ins t a n ce , 
acting as the dient To illustrate this in FIG. 6, each of Ihe 
supervisory managers is coimected to die supervisory server 
by a second line of communication designed 'ireoeiver.** It 
will be understood that these 'Yecdvcr^ connections repre- 
sent a •Reverse" dient/scrver connection, in which die 
^ supervisory server acts as a dient in order to request 
j announcement services from die supervisory noanagers, actr 
ing as announcement servers. 

I In summary, FIG. 6 illustrates the pr^ecred IPC connec- 
tions over which dient/server communications take place. 
The presently preferred embodiment uses a tokenized mes- 
sage paging scheme in which all data is passed back and 
forth between dient and server as ordered pairs of tokens 
and associated data values. The purpose of the token is to 
uniqudy identify the data associated widi iL Referring to 
Table n in the acconq>anying Appendix, a sanq>le listing of 
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tokens is preseixted. Reading the colunms of Table n from 
left to nght liie left-most column lists the token name; the 
column to its immediate light gives a brief descTq)tion of the 
natuze of the value associated wi& the token; the next 
light-most column lists the type declaration of the value; and 
flie li^-most column gives the maximum length of the 
value, where applicable. 

The tokenized message handling scheme is very flexible, 
in that new tokens can be added at any time to accommodate 
new features , without the need to rewrite all client and server 
data structures. This is in contrast to the conventional fixed 
field data structure used in conventional data communication 
schemes. In the conventional, fixed field data structure 
scheme adding a new data value often requires all program 
modules to be rewritten to accommodate the added data 
field. The tokenized message passing scheme of the present 
invention avoids this problem. If a new data field is required, 
to support a new feature, for example, a new token is created 
and only those objects which make use of the new value will 
need to be reprogrammed to scan for the newly added token. 
All lemaining objects S2nq>ly ignore tokens whidi are unde- 
fined for tiiem. 

The presently preferred tokenized message passing 
scheme implements automatic data type conversion. As s^ 
fortii in T;^le II, the type definitions of all values associated 
with tokens are predefined, tims the tokenized message 
passing scheme has advance knowledge of the data types of 
all values. This allows the tokenized message handling 
scheme to perform all data type conversions, removing the 
need for client and server objects to perfonn type conver- 
sions. In other words, a server can pass a long word value to 
a client which is expecting a string value. The tokenized 
message handling scheme performs the data conversion 
automatically so that the server does not need to be aware of 
the client's data type requirements and the client does not 
need to be aware of the server's data type requirements. 

External Processing Manager 

In order to allow the client server logistics management 
system to communicate wi& the outside world, e.g. widi 
external data bases or other t^lication programs, the exter- 
nal processing manager Is jnovided. The external processing 
xoanager is, itself, a client of a supervisory manager, as 
illustrated in FIG. 6. The external processing manager, in 
turn, operates as a server to provide external processing 
functions to other clients. In FIG. 6 the shipping client uses 
the external processing manager for this purpose. 

In the preferred embodiment, the external processing 
interfaces widi the REXX command interpreter 
supplied with the OS/2 operating system. The external 
processing manager Is designed to receive its instructions 
from an ASCn file called a scr^ file. If desired the scr^t file 
can be encrypted to prevent unauthorized access. The scapi 
file conqsises a list of program commands or instructions 
written in the RHXX language, if desired, the REXX lan- 
guage command set can be extended to add additional 
oonamands. This may be done by embedding the additional 
commands in the external processing manager: The external 
processing manager would envoke the REXX interpreter 
and register itself as the source of the additional commands. 
In fills way, fiie REXX interpreter would automatically pass 
(X3ntrol to the external processing manager to han<fie the 
additional coimnands. The external processing manager is 
designed to communicate directly with the REXX 
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interpreter, passing the saipt file commands to Ihe REXX 
interpreter and requesting the ou^t of the REXX inter- 
preter to be directed back to the external processing 
manager, where appropnaX&, In this way, the extemal pio- 
cessing manager is given access to the operating system and 
to all other ^plication programs running on the operating 
system. This is a very powerful command which allows the 
Ic^stics management system to interface widi other appli- 
cations which may not necessarily be designed to integrate 
directly with the logistics management system. For example, 
the extemal processing manager could use the REXX inter- 
preter to send SQL queries to a database, in order to upload 
information about a customer*s account from the accounting 
system software. 

The extemal processing manager's ability to handle 
sciq>ts provides ano&er powerful feature. Scripts may be 
written for the purpose of modifying the performance of 
other program objects conqirising the logistics management 
system. Scripts can be used, for example, change the shq>- 
ments client to provide a reminder message to the user in the 
event Hic user attempts to ship a package without first 
entedng the weight of the package. Similarly, a script could 
be written to change the shipments client to supply a 
convenient list of package dimension sizes, allowing tiie 
operator to quickly fill in the size of a package in the 
appropriate field by simply selecting it firom a list In 
general, the scripting language can be used to provide 
virtually any custom tailoring that a shq>per might want to 
iniplement. The REXX language is straightforward and easy 
to use, thus most customizing to meet the user's require- 
ments can be done in the field, without the need to access or 
modify the underlying program source code. 

In running a script to modify the performance of a 
program object, the extemal processing manager uses ttie 
existing IPC mechanism. Through this mechanism the exter- 
nal processing manager can request a data item stored by the 
object or it may supply a data value as an input to the data 
object In addition, the extemal processing manager can 
request that one or more operations defined for that object to 
be performed. Thus the extemal processing manager serves 
as an alternate to the nconal user interface as a means for 
manipulating data or performing operations. 

From the foregoing it will be seen that the present 
invention provides a logistics management system compns- 
ing a plurality of building blocks or dient^server objects. 
These objects can be configured to communicate in a variety 
of different ways to acconunodate virtually any 
transportation-ielated logistics s^lication. Thanks to the 
dient/server architecture and fiie support for distributed 
architectures, the overall logistics management task is 
^ readily subdivided into hig^ self contained functional 
units. When changes in a given function are required, only 
tfie object providing the function normally needs to be 
changed. The dient/server objects provide furfiier fiexifaility 
, through the extemal processing manager and soq^ing 
I language, ^Itereby individual objects can be modified to 
I provide special features quite readily on an as needed basis. 
, While the invention has been described in its presenfiy 
j preferred form, it will be understood that fiie princq)les of 
the invention may be extended to a wide variety of different 
' forms. Accordingly, the prefened embodiment described 
herein should be considered as exenqilary of the princq>les 
of the invention and not as a limitation of the scope of the 
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TABLE n 

APPENDIX 



VO TOKEN 



VALXIE DESCRIPnOH 



TYPE 

DESCRIPTION 



MAXIMUM 
LENGTTH 



Registry 

Tb TCffstex ft program: 

REGISIER PROGl-BX- ... id from 

PROGRAM PROGESTIil xnadune on 

ID wluch program is xmmmg 

MACHINE Uank if no fkctwofk USD 

grJmachfnc.TiaTiic( ) Eiuctkm 
vsutffsteT a pro^tam: 
ITNREGESIER PROGUD. ... id from 

PROGRAM PROGISnH machine on 

ID which pr ogr am is lanxung 

MACHINE blank if no network use 

ge tmarhin eo am e( ) fimction 
Use this to get a list of AIL programs runnmg in the cnvironmenL If 
HLENAME is blank, iSben eidier the program is not a server gt it is a 
you cannot use. For historical purposes, you may use ENUM SERVER 
wen as ENUM PROGRAM. 
ENXJM 
PROGRAM 
MACHINB 
I 

ID 

NAME 



striqg 



TSfPE 
MACHINB 



ZONE 



FILENAME 



your current/local machiiie 
blank if no network use 
getziuchinename( ) function 
PROG_JD_ ... id from 
PROGISTIH user-friendly 
name of the program FOR 
DISPLAY PURPOSES ONLYtl 
"server type** mask from 
PROGISXLH machine on 
which program is rxmning FOR 
DISPLAY PURPOSES ONLYU 
where is the program n&ming? 

1 s on your local machine 

2 - somewhere else 

pqw name you may use to 
access server - BLANK IF 
YOU CANNOT ACCESS 
SERVER 



string 
strix^ 



usboit 
strii^ 



short 



150 



Use tius to send an anoouncemenL Only inchide the DAIA token if you need 
it (jd uses a queue dot on the recehnz^ machines). You may include one or 
more qwcifie ^^^^r*^ names if you want the ansDUoeement sent to specific 
tmirihtnt^ If you don't ^ecify MACHINE or if it is blank, the annotmcement 
win be sent to all machixfees currently in the e n v ir o nm ent. 

ANNOUNCE ANN. . . . from ANNOUNCEH long string 

ID opdonal string fT^ D ATA 

[DAIA 



I 

[MACHINE 



*^^*Jll^p^ ^l|yT^ machine same 



dti'I^g] 



Miscellaneous 



ANNOUN 
X£N] 



Use tins to close Ae cuviioum enL Tlus is harmless and will not close 
cqyihing diat is not ready to be closed. It win never shut down a marhrne. 
SHUTDOWN 

System Nianbers 

If QUEKY/ENUM/MODIFY SYSNBR is used with an SYSNBR ID diat does 
not yet exist, an entry is automaticaUy added to the nuinber list with these 
defaults: 

LastvahiB (VALUE) 0 

»ed 

Hntin (SIARI) I 



limxt/last in 



(STOP) 



2147483646 



la aU cases* the value passed for TOK*SYSNBR must be non-zao (except 
for ENUM) and uniq\ie within all programs that might ever be nmning in the 
system. The recomnxsidatian is to use the appropiatc TOK_ . . . define for 
your SYSNBR vahie. 
lb got the next number in sequence: 

QUERY see rules above short 

SYSNBR 

YIVLUB next number in sequence kmg 



0 

long) 



o 

111 

m 
m 
a 

£:;i 
in 
m 
a 

w 
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TABLE n-contiiiued 



APPESDDC 



VO TOKEN 



VALTIBDESCRIPnON 



TYPE 

DESCRIPnOM 



MAXIMUM 
ISKGIH 



lb get the status of an entzy in die manber list: 

ENUM see rules above ^jon 

SYSNBR 

ID sboTt 
VALDB see doc above laog 

StAKT seedocabove bag 

STOP see doc above loqg 

INCREMENT see doc above bug 

lb get die status of aU conies ia the nuzober list: 
ENUM 

SYSNBR (no value specified) 

( 

ID diort 
VAUJE see doc above loug 

START see doc above long 

STOP see doc above long 

INCREMENT see doc above lox^ 

...1 

lb change the status of aa entry in the niif n ^f i 
MODIFY 

SYSNBR see rules above short 

VAUUH see doc above - optional long 

START see doc above • optional long 

STOP see doc above - opflonal hmg 

INCREMENT see doc above • optonal long 

If aiQ^ optiosial token is not spedfied^ the preWous value is not ghat^yH Hus 
can be used to change certain numbers without being requized to dtangs 
otheis. For example, if you add to entry and want to use the de&ults £Qr 
START, STOP and INCREMENT but want to specify you own VALUE, you 
cando it 

Shipper Maintrtmrncn 

An of these commands deal with the ma^er list of shippers, t^'^^*^ can 
access the master list via ENUM. An announcement is sent when any slq^per 
infoimatioa of any kind changes. This allows other prpgranos to know when 
they need to do another £Nl}M - espedally if diey are staring additscmal 
shipper infinrna^on in parallel widi this master UsL Other pxogzams '^an use 
IjOCK and UNLOCK to prevent a sh^iper from being deleted *'out £cam under. 



7b get fiiU xafinma^on on all current sh^peis: 
E NUM 
SHIPPER 
I 

ID 

SYMBOL 



Umq;ue ID for diis dupper 
iinitp w* aihqiper short rtam^^. 



string 



NAME 



ERRCODE 

SHFNA 

SHPABBR 

LOCK 

...J 

lb get Ml 
ENUM 



follows C rules for a variable 
user-£rieiidfy shipper name 
FOR DISPLAY PURPOSES 
ONLYII 

TalidiQr/^atus of d iipp er 



SHPAB. 
BRIEN 



SHPAB- 
BRI£N 



shipper abbreviation 
is diaper tocked by some 
prognunL? 
onaB" 



ID 

SYMBOL 
NAME 



SHPKA 

SHBABBR 

LOCK 

Tb diange a shipper's 
MODIFY 



chqiper ID (from ENUM 
SHIPPER) 

umqpielD fortius simper 

tnU^pie dl^ppcr naw w 

follows C rules for a variable 
user-^riexidly s hi p p er 
FOR DISPLAY PURPOSES 
ONLYl! 

validity/status of sUpper 

name/addzess 

slupper aibbieviatum 

is shqiper locked by sozzte 

program? 



SHPAB- 
BRIEN 



strii^ 



SHPNA 



st^per ID (fiom ENU 
SHIPCER) 

shipper abbreviation - optional Strang 



stziz^ 



BRLEN 



SHPAB- 
BRLEN 
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TABLE n-continued 



APPENDIX 



VO TOKEN 



VALUE DESCRIFnON 



TYPE 

DESCRIPnON 



MAXIMUM 
lENGIH 



7b adda shippen 

ADD 

SHIPfER 

lb delete a sb ipp cx: 

DELETE ^Fper ID (from ENUM 

sjHU' wm SHIPPUR). 
lb dKdcHout a sl^iper to a program to prevent deleting: 
LOCK fih ipper ID (from ENUM 

SHIPPER SUIPPbLK) 
PROGRAM PROGUa>_ ... ID from 

PROCHSTLH 

MACHINB on which program is 

numing striog Manir if xio 
zKtwaik use 

getmachineoaine( ) function 
7b check-ia a shipper (UNLOCK): 
UNLOCK shipper ID (6cm ENUM 

SHIPPER SHIPPER) 
PROGRAM PROGUDDU ... ID from 

PROGIOTH 
MACHINE OQ which pr og ram is 

running ^ring blank if no 

netwodc use 

[ ) function 

Commitinent Code 



lb get ^ master list of available commitments; 
ENUM 
COMMIT- 
MENT 
[ 

ID 

SYMBOL 
NAME 



...] 

sTDurr 

{MANIFEST 
I 

SmPDATB 

SHIPPER 

DQNTBAND 

SERVKE 

FKGTYFE 

PAYTYEB 

EAYORACCT 

"WEIGHT 
REF 



LENGTH 
WIDTH 

RCPID 



RCP- 

CONIACT 



COMBUIY 
RCPADDRl 
RCPADDR2 

Rcpcrry 

RCPSXAXB 

DEST 

RCPPHONE 



COMMIT. ... ID from RAIERJI 
ComPi i ^i v^*^^ short twth^ 
follows C rules for a variable 
user-friendty ''*^'"}^*r'}rT \* 
jam FOR DISPLAY 
PURPOSES ONLYlt 
use manifest mode? 
/• defuilt pack^e info */ 

date (IDC) 
ID 

don*t band yet 
ID (see FDXRATER-H) 
ID (see RAIERJQ 
payment type (see RAIERJI) 
payor account number 



blru^g 



undefined 



undefined 



package lenglb 
package widdi 
package betabt 
ircipicnt ID 



recqnent c 



boolean] 



ksngO 

sfaortO 

boolean 

dtort 0 

fifaoitO 

shortO 

string 

btriug 



fifaortO 
shoitO 
short 0 
btrixtg 



oUliig 



lecjpjeoit con^pai]y uuiiifi 

lec^jent address lino 1 
recipient address line 2 



recipient state 
postal code 

yp^ypiflfit phone Quzubcr 



UFDX_- 
PAYOR 

IJEN_RB- 

FER. 

ENCB 



LEN,J B- 
CIFIENT- 
ID 

NALEN_- 
CON- 
TACT 
NALEN-- 
COM- 
PANY 
NALEH-.- 
ADDR 
NALEN-.- 
ADDR 
NAI£N.- 

cmr 

NAIEN_- 

SIAEB 

NA££^C- 

MAX- 



i 

20 



Q 
Ml 

m 
m 

r uiS i^AGE BLANK (USPTO) 

c::i 
in 

fij 

m 



t 
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TABLB n-CQntinned 



APPENDIX 

TYPE MAXIMUM 
VO TOKEN VALUE DESCRIPnQN DESCKIPnON lENGIH 



FHONB- 
LEN 



CODAMOUNT 

CODTYIE 

HAZ 



PIRECTDEL 

S^OBEL 
TfECVAL 

] 

HEM 

usrnD 
[ 

SMPDAEE 

SHIPPER 

DONIBAND 

SERVICE 

FKGTVPB 

PANTVFE 

PAYORACCT 

WEIGHT 
KEF 



I £NGI H 

wnnH 



RCPID 
RCP- 

CONIACT 
RCP. 

COMBANY 
RCRADDRl 
RCPABDR2 

Hcpcnr 

KCPSLfJB 

BEST 

RCPPHONE 



CODAMOUNT 

CODTYFE 

HAZ 



H OLD 

SXEDSL 

VECVAL 

1 

MSK 



COMMIT- 
MENT 
ARRIVE 
DDfWT 
(IRACKKBR 

CQDKETTRK 
CONIENTS 



CODi 
logical OR of COD.... 

&3Z8ldD1XS flSBtCHflls? 

y ^ T P tiim xdease? 
i&ect delxveiy ^>ix^)? 
hold for delxvoy? 
Saturday delivery? 
dedaxed vahie 

we^g^ of diy ke (wbok lbs) 

Dcxt package list ID 

id 

date CTDC) 
ID 

don't band yet 
ID (see FDXRATERJI) 
ID (seeRAIERJI) 
bayment type (see RATER-H) 
payor account ouiziber 

Weight 
lefiereQce 



padcage leqgtfa 
package width 
package height 
lecipient ID 



ledpient contact same 

lec^tent oonqmiy same 

sccxpicst address line 1 
ffftiptmt address line 2 
iecq)ient Gty 
xecqttent state 
postal code 

xBc^icQt phone number 



Iai|g2 



CODs 
logical OR of COD_ . . . 
hazardous matexials? 
sagm lur e re l ease? 
direct deliveiy (Dingile)? 
hold for delive^ 
Saturday deUveiy? 
declared value 

weight of dry ioe (^^ude lbs) 
ID 

loutii^code 

code (see RAIERil) 

date (TDC) 

cfimenstonal wci£^ 

tiadaqg nnmbei/COD tracking 

« 

COD letum tracking number 
/* unored for now */ 



knig 0 
fihortO 

lo^g 0 

loogO 

longO 

shortO 

boolean 

short 0 

sbortO 

shortO 

strix^ 

long 3 
string 



shortO 
shortO 
shortO 
strizig 



strizig 



strii^ 



strixtg 



laqg2 
short 
boolean 
boolean 



boolean 
boolean 
kxtgO 
dioitO 

longO 

string 
ahortO 

longO 
short 0 
string 



IPDX_- 
PAYOR 

IEN_RB. 

FER- 

ENCE 



mL-R E- 
f 'IPIKNT- 

3D 

NALEK_- 

OON- 

TACT 

NALEN-- 

COM- 

PANY 

NALEN_- 

ADDR 

NAl£N«- 

ADDR 

NAim-- 

crry 

NAtEN-- 

STAIE 

NALENL- 

7TP 

MAX. 

PHONB- 



111 
111 



# # 
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TABLE n-continued 



APPENDIX 



irO TOKEN 



VALUE BESCRIPnON 



TYPE 

DESCRIPnON 



MAXIMUM 
LENGIH 



IJS'ilD 

COD 

DECVAL 

HA2 

SAIDEL 

SAIFU 

ALASKACHO 

UAWAnCHG 

DIMRAEE 

END 

ushd 

iPELEIE 
t 



ID 

see SERVEZLDOC 
COD cfaaise 
declared value chaige 
dai^gexoas £oods charge 
Saturday delivery chaise 
Saturday {adcup cbaijge 
Alaska delxvexy chaxge 
Hawui delivery chaise 
azijr package DIM rated? 

ID 

true to just Unow list away 
/• if manifest •/ 
see SERVER JKX: 



kngO 

kmg 2 
kmgl 

lODg 2 

laag 2 
loqg 2 

lOQg 2 

lo^g 2 
boolean 

lOQgO 

boolean] 



MSN 



listof MSNs 



1 

VOID returns a list of other MSKs whose data was changed Package 
ctocumentation should be reprinted and any data saved should be QUERYed 
again. 
VOID 
ID 
I 

MSN 

...1 
UST 
B AND 
SHIPPER 

r 

NAME 
ID 
...J 
LIST 
DEL 

[TRANSMrr] 
SHIPPER 
[ 

NAME 
ID 
,..] 
LIST 

TRANSMIT 
SHIPPER 
[ 

NAME 
ID 

...] 

(see PRINT section - SERVERJ>OC) 
LIST 
PRINT 



ID 

(£splayablc fionn of shipdate 
thiz^ to pass to band 



displayable ^ghi pd atift & 



ID 



shipdate & <a»<jiim^ 



lOQgO 
lOQgO 



short 0 

string 
longO 



short 0 

string 
string 



short 0 

string 
strins 



18 



21+ 
12 



21+ 
12 



BAND 

SmPfER 

ID 

ID 

DEL 

(TRANSMir] 
I 

ID 

...] 

(see PRINT 
PRINT 

JD 

MSN 

(PRINT- 
ERROR 



MSN 



ID 

tfamg returned from LIST 



fflwiamft (returned from UST) 

SERVERJXX:) 

/* courier & summaiy report */ 
fti^^TTt^ (returned from LIST) 
/* ASTRA label*/ 
package master sequence 
nmnbcx 

ignore print euui? 

/* rate chart •/ 
ID 

/•air«n-/ 

pack^e master sequence 



short 0 
longO 



string 

string 
kqgO 
boolean] 

shortO 
longO 



12 



12 



12 
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TABLE n-CQntinued 



APPENDIX 

TYPE MAXIMUM 
I/O TOKEN VALUE CESCRIPnDN BESCRIFTIOK I£KGIH 



[MORE 
QUERV 
PRINT 
(seePEUNT 



booleaa] 



. SEKVBRDOC) 



QUERY 

riKM 

(see (ENUM section - SERVER JX>C) 

E NUM 

SHIPPER 

[ 

SYSNBR 
ACCOUNT 
USER 
FWD 
PWD 
USER 
ORIGIN 
IRACKNBR 
TRACKNBR 
CQDTRK 
COD TRK 
CODREITRK 



CODREZTRK 

SKjREL 

PWRSHP 

DIMRATB 

GNDSAVER 

...1 

ENUM 

C ONTRO L 

SHIPPER 

TRACKNBR 



COniRK 

CODRETTRK 

COUNT 

COUNT 

ENUM 

CONHD 

DIAL 

BAUD 
PORT 

Dm 



POWERSHIP plus number 
FedEx ac^uot nuosber 
EN user td 
EN password 
IE password 
recipient user ID 
ori^m stfttiou 
first traddog xuuiiber 
last tracknig number 
first COD trackxpg nmnber 
last COD trackintg number 
fixstCOD letum tracking 
number 

last COD return tracking 



string 



string 
string 



string 
string 



signature release atithorizatioTi 



PO WERSHIP phis complaint 
use ^ iH K i ii5i*i ? p^l ratu^ 
use Express saver 



ID 

last package tracking number 
used 

last COD tracking number 
used 

last COD return tracking 



sttxqg 

strxQg 

strxpg 

boolean 
boolean 
boolean 



cycle count 
transfer count 



Haycs-compatibic dialout 



baud rate 

pOit 



sttipg 

longO 
long 0 



strii^ 

short 
short 



t each element 



see i*L93iit Ai KK H for more ^fty npoH o n c 
M ODIFY 

SHIPPER ID 
[see ENUM SHIPPER section] 
MODIFY 
C ONTRO L 

sHnraR ID 

[see ENUM CONTROL sectioo] 

MODIFY 

CONFIO 

(see ENUM CONTROL section] 

(after END with MANIFEST TRUE, use this to chan^ item infonnatksn) 
HEM 

MSN package master sequence longO 

(PONIBAND don't baud yet boolean] 

/*8ee RArBR.C */ 

LOCK 

SHJPWiR ID 



LFDX_- 
DIAL 



LFDX_- 
PAIH 
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